The term “engineering” used in the following implicates all possible actions in the context of software architectures of complex cyber-physical systems used in different technical domains, such as the maintaining of software architecture of complex cyber-physical systems.
The term “cyber-physical system” used in the following refers to a system of collaborating computational elements controlling physical entities (cf. http://en.wikipedia.org/wiki/Cyber-physical system in the version of Jul. 23, 2014), whereby the technical domains could be as diverse as areas like aerospace, automotive, chemical processes, civil infrastructure, energy, healthcare, manufacturing, transportation, entertainment, consumer appliances etc. and include technical capital and/or producer goods.
The term “software architectures” used in the following refers to a high level structure of a software system, the discipline of creating such a high level structure, and the documentation of this structure (cf. http://en.wikipedia.org/wiki/Software architecture in the version of Jul. 24, 2014). Thus, when in the following the term “software architectures” is used all software structures of complex cyber-physical systems of different technical domains should be covered.
The architectural aspects of a large and complex cyber-physical system are typically captured in a large number of system models called “Views”.
With regard to such a method or tool it is known the following:
I. Low-level Graph Rendering
Low-level drawing and layout toolkits, like “Graphviz” in [1], and libraries, like “Eclipse Zest” in [2], help the user to render information visually as graphs with nodes and edges. However, the default output of these tools is often not categorized and requires lots of customization to get the desired results.
“Graphviz” only knows about nodes and edges and relies on the user to give directions regarding the grouping of nodes and their placement. “Graphviz” supports generic layout algorithms like “dot”, which is a tool. It is up to the user to design his own visualization using the lower level building blocks that
“Graphviz” provides. In addition, “Graphviz” is only a renderer and cannot support interactive usage. Libraries like “Eclipse Zest” allow the user to create interactive renderings; however, the user still has to design the representation that is pertinent to the problem.
II. Levelization Algorithm
The basic levelization algorithm of determining levels for dependencies was first described by “John Lakos” in [3]. Levelization assigns a number to each software artifact based on its dependencies. Components external to the system are level 0, system components which do not have any dependencies are level 1. Components which depend on level 1 components are considered level 2 and so on. However, an explicit representation of the result of the analysis is not prescribed.
In a cheat sheet describing “NDepend implementation of the levelization algorithm” in [4], an illustrative representation is found.
This representation visually separates layered, tangled and third-party artifacts, but does not offer facilities like grouping to manage large diagrams. It also doesn't specify any interactive adaptations to make the diagnosis more efficient. In contrast, it explicitly addresses scaling the representation for real-world scenarios, while also extending the basic representation to support software evolution information.
III. Hierarchical Views
The “Simple Hierarchical Multi-Perspective (SHriMP)”—tool according to [5] showing composite edges and nested nodes allows users to view complex information spaces software dependencies and knowledge bases. The tool provides hierarchical views that allow the user to drill down and explore complex graphs. The user can toggle the layouts used to render the nodes, e.g. use a Tree Layout or Grid Layout. The edges can also be aggregated to composite edges that are easier to give an overview of. However, it does not support software evolution information, partitioning of the nodes into categories according to criteria, cycle detection and more importantly the levelized view of the nodes.
The Levelized Structure Map (LSM) from “Structure101” in [6] is also a hierarchical view of software dependencies. The LSM supports identifying cycles of dependencies and can do layer analysis regarding architectural constraints.
An additional graph view provided by “Structure101” is showing graph diagrams that are clustered generically by the cycles in dependencies (Showing Tangles In Dependencies). However, these views do not support an evolution view that relates maintenance events for a more comprehensive understanding of why such a tangled dependency was introduced.
Integrated Development Environments (IDEs) like Visual Studio and Eclipse also have plugins that also provide similar views but they suffer the same limitations.
IV. Dependency Structure Matrices
Popular commercial tools like “Lattix” according to [7] and “NDepend” according to [8] rely on a visualization based on the Dependency Structured Matrix. The entities under consideration are placed in an n x n matrix, with cells that are used to indicate dependency information. For example, if an entity i, depends on entity j, then the cell (i,j) could be filled in with a special mark, or some metric that represents the number of dependencies.
With sufficient training, a user can interpret large graphs of dependencies. However, they are not as comprehensible as node and edge diagrams, and also don't convey software evolution information.
For engineering or maintaining software architectures/structures of software systems with its various software artifacts it should be considered the following:
(A) Huge Amount of Dependencies in Software Systems
A majority of the efforts (and hence, cost) during a software product's lifecycle goes to maintaining the software: enhancing the software system with new features as required by market demands and fixing defects found in operation. The maintainability of a software product is directly influenced by the manner in which various software artifacts like subsystems, components, packages and classes depend on each other. Each tightly coupled artifact is hard to be replaced or be relocated to other locations of the overall software system structure. If a system has several artifacts that are tightly coupled together, making a change in one artifact can cause a cascading change in the directly depended artifacts. This leads to increased compile and link times, larger regression tests to be performed, extended time to comprehend the overall structure and implications of a change, hence leading to increases of engineering time and higher maintenance costs.
(B) Information Overload Due to Automated Extraction of Dependencies
It is possible to use automated methods to extract dependency information from software artifacts. However, the amount of information collected is very large, and cannot be understood in the raw form. The amount of data has to be presented in a scoped manner in order to avoid overwhelming the user.
(C) Lacking Information About the Relation with Other Evolution Information
Dependency relations alone are often not enough in answering questions facing the system architect. It is helpful to take into account how the dependencies evolved during the course of the development. This can answer questions like “Which issue caused this dependency cycle to get added to the system?” allowing architects to identify and remedy situations that cause unwanted coupling to occur.